<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"><p>
<!-- $Id$ -->
<html> <head>
<title>Component-Integrated ACE ORB - TODO list</title>
</head>

<body>
<h1>Component-Integrated ACE ORB (CIAO) - TODO list</h1>

The following is a prioritized list of things (with the highest
priority items first) that the DOC group is working on. The expected
date of accomplishments are also added as ETA (expected time of
accomplishment) :

<h3>Things to do:</h3>
<ul>
  <li> Integrate TAO's real-time event channel within the
  container. Components can use this feature to communicate using
  <CODE>eventtype</CODE>s a pub-sub mode. The code is available in a
  branch and it needs to be integrated in to the main-trunk. (ETA -
  2004/08)
  </li> <p>

  <li> Allow components (i.e., assemblies) to be connected using the
  NameService (ETA - 2004/08) </li> <p>

  <li> Allow non-component enabled clients to access reference to a
  component or an assembly using NameService (ETA - 2004/08) </li> <p>

  <li>Allowing components to set attributes, atleast attributes of
  basic types. As a first step we need to implement the
  <CODE>StandardConfigurator</CODE> interface. The servant for the
  <CODE> StandardConfigurator</CODE> interface should be implemented
  and activated by the servant for the component. DAnCE can extract
  the reference from the servant and use it to set attributes  (ETA -
  2004/08)</li><p>

<li>Now that we have supports for ccm_{activate,passivate,remove}, we
    need to rethink how a container manages the lifecycle of all the
    components/homes it hosts so all the servants related to a
    component get destroyed "properly". The aforementioned
    SessionComponent operations will also depend on the proper
    lifecycle management. <p>

    This includes making sure all components' appropriate
    ccm_passivate and ccm_remove operations are called when the
    ComponentServer is closing down.<p> (ETA - 2004/08) </li>

  <li> Migrate RT features from RTComponentServer to DAnCE
  (ETA - 2004/10) </li> <p>

  <li> Static configuration of components using DAnCE (ETA - 2004/12)
  </li> <p>

  <li>We need a set of tests to make sure most (and later
   all) of the data types are function correctly (in term of CIDL
    generated code).  More importantly, we need to make sure all the
    component keywords are supported okay. (ETA - 2004/07)<p>

  <li>The naming convention used in <a
      href="new_component.html">creating new component
      instructions</a> and that used in <a
      href="templates/">templates</a> do not match.  (Files containing
      glue code are named *_svnt.* and *GS.* respectively.)  We need
      to address that.(ETA - 07/2004) <p> </li>

  <li> Retire the old assembly and deployment framework (ETA -
  2004/10) </li>

  <li>We need to review the implementation of servant glue code and
   container implementations to make sure that they are
   thread-safe, if the container calls for it.  Currently, these
   states are changed only by the deployment framework which always
   runs in single thread, so it's not a serious problem.  However,
   it's perfectly legal to dynamically configure connnections, which
   will be the case if we want to add new components or remove
   components from the assembly.(ETA - 2004/09)<p>

  <li> Add support for creating a thread pool within the the component
  server. We don't have support for this, which has made our users
  resort to spawning threads within the components, which breaks
  portability of the executor code. (ETA - 2004/09)  </li> <p>

  <li> At present components in an assembly have no way of knowing
  whether the assembly is complete or not. This becomes important when
  there are hierarchical assemblies, and the assembly at a higher
  level needs to pass on attrbute information to the assembly at a
  lower level. The spec talks about <CODE> configuration_complete ()
  </CODE> whose semantics are a bit unclear. We may have to use this
  to inform the components that the configuration is infact
  complete. (ETA - 2004/09)</li><p>

 <li> We have now two proprietary methods in the <CODE>
 SessionComponent </CODE> interface called <CODE> ciao_preactivate ()
 </CODE> and <CODE> ciao_postactivate () </CODE> which has to be
 overridden by the executor code irrespective of whether the executor
 implements them or not. These were added to help components to know
 activation status of other components in the assembly. This could
 create problems for interoperability of the executor code. A better
 to way is to have the CIDL generate C++ code instead of executor IDL.
 The generated C++ code from the CIDL could provide default
 implementations which could be overridden by the executor code if so
 desired. This would make the executor code more portable. Obviously
 we also should retain executor IDL generation using some command line
 options. (ETA - 2004/09). </li> <p>

<li> Need to develop tools that would allow components to be added
  dynamically to an existing assembly and remove components
  dynamically from an existing assembly (ETA - 2004/12) <li> <p>.

<li>The CCM_Core libraries need to be refactored so regular CIAO
    users no longer need to link to CIAO_Server but to
    CIAO_Container library instead.  Currently, the session
    container implementation is throwing exceptions from the
    deployment modules when it fails to install a home.  But these
    feature should really be implmented in the Deployment::Container
    interface instead. (ETA - 2004/12)<p>

<li>HomeRegistrar related files from the CCM_Core  projects have
    been removed.  We need to move them into a new directory when we
    get to a new HomeFinder/HomeRegistrar implementation.  Notice
    that the deployment framework will need to use the HomeRegistrar
    interface to register components/homes. (ETA - 2004/12)<p>

<li>We should add support for the unclassified container and use the
    property file of some sort to configure the empty container.<p>

    Process component (which have 1:1 servant to OID mapping) might
    be useful too (no need to support PSS in this case?)<p>

    Persistent object references/IDs can be useful for statically
    configured DRE systems as they eliminate the initial handshakes
    in a multi-process system and enable each process to start up
    independently. (ETA - Not known) <p>

  <li>The new <code>generate_component_mpc.pl</code> script should
      invoke the <code>generate_export_file.pl</code> automatically
      and created the necessary export files instead of only printing
      out the hints on how to do that. (ETA - Not known)<p>

  <li>We need a ConfigValues parser for extracting common name-value
      info out of a ConfigValues sequence. This would be needed if
      components have to set complex user defined types as attributes.
      (ETA - not known). </li><p>

  <li><b>Container Factory</b>: We need to provide a container factory
      interface to decide what kind of container we need to use.  Hmm,
      isn't this the job of <code>ComponentServer</code> interface?
      (ETA - not known)</li><p>

  <li><b>ComponentInstallation</b>: This is a simple interface that
      provides (UUID, Location) mappings.  Both UUID and Location are
      of string type.  Since ACE supports UUID implementation, we can
      probably use that to generate a UUID. Location should be URI, but
      let's just map that to locations in filesystem (pathnames) for
      now.  So we will most likely need to provide more downloading
      mechanisms in the future, e.g., http, ftp, etc. <p>

      ComponentInstallation is the interface assembly mechanism used
      to interact with the deployment mechanism.  We are free to
      implement the deployment mechanism (i.e., shipping of code to
      various locations of application domains)  the way we like but
      the assembly mechanism depends on this interface to determine
      where to fetch a specific implementation.<p>

      One thing that we really need is an installation tool set which
      can be used to manage remote installation, by parsing various
      XML descriptors and either push or pull the right implmentation
      for a certain host in the list of hosts the component need to be
      installed.  According to the CCM spec., ComponentInstallation
      interface implementation can retrieve a implementation (DLL) on
      an on-demand basis.  Therefore, there is probably no need to
      push the appropriate DLL over right away when we feed some
      descriptors into the installation tool.   The tool, however,
      should accurately extract the correct OS/compiler information
      and inform the ComponentInstallation impl which and where to
      fetch the right implmentation for the host it is running on. (ETA - not
      known)<p>
  <li><b>CIDL Compiler</b>:
      There are no immediate plans to support the part of CIDL
      corresponding to the OMG Persistent State Definition Langauge
      (PSDL). For an up-to-date status of the CIDL, please see
      $CIAO_ROOT/CCF/Documentation/TODO.

  <li> This is a set of the to-do associated with the DAnCE implementation.
  <p>
  <ul>
      <li>We need to put the ComponentServer layer back in. In the current
          implementation we use NodeApplication as both the Session Container
	  and the ComponentServer. We need to seperate the two
          entities so we can hook any Container with the
          ComponentServer. This change is essential to the RT
          configuration and for the future of CIAO.<p>

      <li>Bala added ciao_[pre|post]_activate to the Session Component to
          force the order of actions upon start-up, but this will not
	  work with the new DnC framework. We need to change the DnC framework
	  a bit to make this feature available again.<p>

      <li>We need to work on the Resource Management process in
          DAnCE. Right now this part of the DnC spec is omitted in our
          implementation.<p>

      <li>We need to work on the packaging process more so we can ship
          binaries around when the dll/so is not available in the
          local node.<p>
  </ul>

</ul>

<h3>Cool ideas</h3>
<ul>
  <li>Currently, developing a component will create 3 DLLs, one for
      the client side stuff, one for the servant glue code, and one
      for the executors.  We need to figure out a way to automate
      these stuff.  MPC is a good starting point to generate scripts
      to create project templates.<p>

  <li>Management of <code>ComponentInstallation</code> can be done
      using a CORBAscript of some sort as this involve mostly
      registering and unregistering of locations of component
      implementations.<p>
</ul>

<h3>Finished Work</h3>
<ul>
  <li>The exception returned from CIAO_Daemon when it fails to
      locate a DLL is quite useless to say the least.  It needs
      fixing.<p>

      CIAO now provides more meaningful error message now.<p>

  <li>We should create a new workspace/target in TAO such as CIAO_ONLY
      to simplify the process of using CIAO.  Currently, you have to
      checkout the README file in CIAO_ROOT to figure out what TAO
      modules are required by CIAO.<p>

      A new target "CIAO_Core" is now available in ACE's top level
      Makefile.<p>

  <li>We need better debug info and a way to control how different
      level of debug info are generated in CIAO.<p>  Some preliminary
      support using the <a href="EnvVars.html">environment
      variable</a> <code>CIAO_DEBUG_LEVEL</code> has been added.<P>

  <li>Miminal implementation of CIDL compiler.<p>

  <li>CCM core workspace now contains 3 different DLLs:
      <UL>
        <li>CCM_Client - Needed by CCM-awared client
        <li>CCM_Container - Needed by executors and servers
        <li>CCM_Server - Needed by servers and CIAO tools
      </UL><p>

  <li>A SessionContainer implementation.<p>

</ul>

</body> </html>
